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Why Are the Digital Humanities So White? 
or Thinking the Histories of Race and Computation 


TARA MCPHERSON 


n mid-October 2008, the American Studies Association (ASA) hosted its annual 

conference in Albuquerque, New Mexico. According to its website, the ASA “is 

the nation’s oldest and largest association devoted to the interdisciplinary study 
of American culture and history.” Over the past two decades, the ASA conference 
has emerged as a leading venue for vibrant discussions about race, ethnicity, trans- 
nationalism, gender, and sexuality. While the ASA represents scholars with a diverse 
array of methodological approaches from a variety of disciplines, the society is a 
welcome home to academics whose work is interpretative and theoretical. During 
the meeting, I attended a variety of panels engaging such issues and approaches and 
came away feeling energized and refreshed, my intellectual imagination stoked by 
the many ways in which race and ethnicity were wielded as central terms of analy- 
sis throughout the long weekend. 

The following week, I was off to Baltimore where I attended “Tools for Data- 
Driven Scholarship,” a workshop funded by the National Science Foundation (NSF), 
the National Endowment for the Humanities, and the Institute of Museum and 
Library Services. This invitation-only event was cohosted by George Mason Uni- 
versity’s Center for History and New Media (CHNM) and the Maryland Institute 
for Technology in the Humanities (MITH), two pioneering centers of what we have 
recently begun to call the “digital humanities.” This workshop built upon several 
years’ conversation (particularly following the 2003 NSF Atkins Report on cyberin- 
frastructure) about the need for a digital infrastructure for humanities computing. 
The goal of the workshop was defined in the e-mail invite as a report “that discusses 
the needs of tools developers and users; sets forth objectives for addressing those 
needs; proposes infrastructure for accomplishing these objectives; and makes sug- 
gestions for a possible RFP.” This meeting was also lively, full of thoughtful discus- 
sions about the possibilities for (and obstacles in the way of) a robust infrastructure 
for scholars engaged in computation and the humanities. The conversation certainly 


[ 139 


140 | 


TARA MCPHERSON 


fired up my technological imagination and subsequently led to useful discussions 
with my collaborators in technological design.' 

As I flew home following this second event, I found myself reflecting on how 
far my thoughts had ranged in the course a mere week: from diaspora to database, 
from oppression to ontology, from visual studies to visualizations. And, once again, 
I found myself wondering why it seemed so hard to hold together my long-standing 
academic interests in race, gender, and certain modes of theoretical inquiry with my 
more recent (if decade-old) immersion in the world of digital production and design. 

While the workshop I participated in at ASA was titled “American Studies at 
the Digital Crossroads” and drew a nice crowd, the conference as a whole included 
remarkably little discussion of digital technologies (although there were some analy- 
ses of digital texts such as websites and video games.) It is largely accurate, if also a 
generalization, to say that many in the membership of the ASA treat computation 
within the humanities with some level of suspicion, perceiving it to be complicit 
with the corporatization of higher education or as primarily technological rather 
than scholarly.’ (Indeed, this attitude is shared by a large number of “traditional” 
humanities scholars across any number of fields or professional societies who do 
not work with digital media.) In a hallway chat following our workshop, one scholar 
framed his dis-ease as a question: “Why are the digital humanities, well, so white?” 
And while my memory is far from perfect, I think it is safe to say that the Baltimore 
workshop included no discussion of many topics much in evidence at ASA, top- 
ics including immigration, race, and neoliberalism. To be fair, this was a workshop 
focused on the notion of tools and infrastructure, so one might not expect such 
discussions. Nonetheless, this essay will argue that we desperately need to close the 
gap between these two modes of inquiry. Further, I will argue that the difficulties 
we encounter in knitting together our discussions of race (or other modes of dif- 
ference) with our technological productions within the digital humanities (or in 
our studies of code) are actually an effect of the very designs of our technological 
systems, designs that emerged in post-World War II computational culture. These 
origins of the digital continue to haunt our scholarly engagements with comput- 
ers, underwriting the ease with which we partition off considerations of race in our 
work in the digital humanities and digital media studies. 


U.S. Operating Systems at Midcentury: The Intertwining of Race and UNIX 


Let us turn to two fragments cut from history, during the 1960s. 


FRAGMENT ONE 


In the early 1960s, computer scientists at MIT were working on Project MAC, an 
early set of experiments in Compatible Timesharing Systems for computing. By 
1965, MULTICS (Multiplexed Information and Computing Service), a mainframe 
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timesharing operating system, was in use, with joint development by MIT, GE, 
and Bell Labs, a subsidiary of AT&T. The project was funded by ARPA (Advanced 
Research Projects Agency) of the Defense Department for two million dollars a year 
for eight years. MULTICS introduced early ideas about modularity in hardware 
structure and software architecture. 

In 1969, Bell Labs stopped working on MULTICS, and that summer one of 
their engineers, Ken Thompson, developed the beginning of UNIX. While there are 
clearly influences of MULTICS on UNIX, the later system also moves away from 
the earlier one, pushing for increased modularity and for a simpler design able to 
run on cheaper computers. 

In simplest terms, UNIX is an early operating system for digital computers, 
one that has spawned many offshoots and clones. These include MAC OS X as well 
as LINUX, indicating the reach of UNIX over the past forty years. The system also 
influenced non-UNIX operating systems like Windows NT and remains in use by 
many corporate IT divisions. UNIX was originally written in assembly language, 
but after Thompson’s colleague Dennis Ritchie developed the C programming lan- 
guage in 1972, Thompson rewrote UNIX in that language. Basic text-formatting 
and editing features were added (i.e., early word processors). In 1974, Ritchie and 
Thompson published their work in the journal of the Association for Computing 
Machinery, and UNIX began to pick up a good deal of steam.* 

UNIX can also be thought of as more than an operating system, as it also 
includes a number of utilities such as command line editors, APIs, code libraries, 
and so on. Furthermore, UNIX is widely understood to embody particular philos- 
ophies and cultures of computation, “operating systems” of a larger order that we 
will return to. 


FRAGMENT TWO 


Of course, for scholars of culture, of gender, and of race like the members of the 
ASA, dates like 1965 and 1968 have other resonances. For many of us, 1965 might 
not recall MULTICS but instead the assassination of Malcolm X, the founding of 
the United Farm Workers, the burning of Watts, or the passage of the Voting Rights 
Act. The mid-1960s also saw the origins of the American Indian Movement (AIM) 
and the launch of the National Organization for Women (NOW). The late 1960s 
mark the 1968 citywide walkouts of Latino youth in Los Angeles, the assassina- 
tions of Martin Luther King Jr. and Robert E. Kennedy, the Chicago Democratic 
Convention, the Stonewall Riots, and the founding of the Black Panthers and the 
Young Lords. Beyond the geographies of the United States, we might also remem- 
ber the Prague Spring of 1968, Tommie Smith and John Carlos at the Mexico Sum- 
mer Olympics, the Tlatelolco Massacre, the execution of Che Guevara, the Chinese 
Cultural Revolution, the Six-Day War, or May 68 in Paris. On the African conti- 
nent, thirty-two countries gained independence from colonial rulers. In the United 
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States, broad cultural shifts emerged across the decade, as identity politics took root 
and countercultural forces challenged traditional values. Resistance to the Vietnam 
War mounted as the decade wore on. Abroad, movements against colonialism and 
oppression were notably strong. 

The history just glossed as “Fragment One” is well known to code junkies and 
computer geeks. Numerous websites archive oral histories, programming manuals, 
and technical specifications for MULTICS, UNIX, and various mainframe and other 
hardware systems. Key players in that history, including Ken Thompson, Donald 
Ritchie, and Doug Mcllroy, have a kind of geek-chic celebrity status, and differing 
versions of the histories of software and hardware development are hotly debated, 
including nitty-gritty details of what really counts as “a UNIX.” In media studies, 
emerging work in “code studies” often resurrects and takes up these histories.° 

Within American, cultural, and ethnic studies, the temporal touchstones of 
struggles over racial justice, antiwar activism, and legal history are also widely rec- 
ognized and analyzed. Not surprisingly, these two fragments typically stand apart 
in parallel tracks, attracting the interest and attention of very different audiences 
located in the deeply siloed departments that categorize our universities. 

But why? 

In short, I suggest that these two moments are deeply interdependent. In fact, 
they coconstitute one another, comprising not independent slices of history but 
instead related and useful lenses into the shifting epistemological registers driving 
US. and global culture in the 1960s and after. 

This history of intertwining and mutual dependence is hard to sketch. As one 
delves into the intricacies of UNIX (or of XML), race in America recedes far from 
our line of vision and inquiry. Likewise, detailed examinations into the shifting reg- 
isters of race and racial visibility post-1950 do not easily lend themselves to obser- 
vations about the emergence of object-oriented programming or the affordances 
of databases. Very few audiences who care about one lens have much patience or 
tolerance for the other. 

Early forays into new media theory in the late 1990s and much concurrent 
work in the computational humanities rarely helped this problem. Theorists of 
new media often retreated into forms of analysis that Marsha Kinder has critiqued 
as “cyberstructuralist,” intent on parsing media specificity and on theorizing the 
forms of new media while disavowing twenty-plus years of critical race theory, 
feminism, and other modes of overtly politicized inquiry. Much of the work in the 
digital humanities also proceeded as if technologies from XML to databases were 
neutral tools.° Many who had worked hard to instill race as a central mode of anal- 
ysis in film, literary, and media studies throughout the late twentieth century were 
disheartened and outraged (if not that surprised) to find both new media theory 
and emerging digital tools seem indifferent to those hard-won gains. 

Early analyses of race and the digital often took two forms: first, a critique of 
representations in new media or the building of digital archives about race, modes 
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that largely were deployed at the surface of our screens, or, second, debates about 
access to media—that is, the digital divide. Such work rarely tied race to the anal- 
yses of form, phenomenology, or computation that were so compelling in the 
work of Lev Manovich, Mark Hansen, or Jay Bolter and Richard Grusin. Impor- 
tant works emerged from both “camps,” but the camps rarely intersected. A few 
events attempted to force a collision between these areas, but the going was tough. 
For instance, at the two Race and Digital Space Conferences colleagues and I orga- 
nized in 2000 and 2002, the vast majority of participants and speakers were engaged 
in work in the two modes mentioned earlier. The cyberstructuralists were not in 
attendance. 

But what if this very incompatability is itself part and parcel of the organiza- 
tion of knowledge production that operating systems like UNIX helped to dissemi- 
nate around the world? Might we ask whether there is not something particular to 
the very forms of electronic culture that seems to encourage just such a movement, 
a movement that partitions race off from the specificity of media forms? Put dif- 
ferently, might we argue that the very structures of digital computation develop at 
least in part to cordon off race and to contain it? Further, might we come to under- 
stand that our own critical methodologies are the heirs to this epistemological shift? 

From early writings by Sherry Turkle and George Landow to more recent work 
by Alex Galloway and others, new media scholars have noted the parallels between 
the ways of knowing modeled in computer culture and the greatest hits of struc- 
turalism and poststructuralism. Critical race theorists and postcolonial scholars like 
Chela Sandoval and Gayatri Spivak have illustrated the structuring (if unacknowl- 
edged) role that race plays in the work of poststructuralists like Roland Barthes and 
Michel Foucault. We might bring these two arguments together, triangulating race, 
electronic culture, and poststructuralism, and, further, argue that race, particularly 
in the United States, is central to this undertaking, fundamentally shaping how we 
see and know as well as the technologies that underwrite or cement both vision and 
knowledge. Certain modes of racial visibility and knowing coincide or dovetail with 
specific ways of organizing data: if digital computing underwrites today’s informa- 
tion economy and is the central technology of post-World War II America, these 
technologized ways of seeing and knowing took shape in a world also struggling 
with shifting knowledges about and representations of race. If, as Michael Omi and 
Howard Winant argue, racial formations serve as fundamental organizing prin- 
ciples of social relations in the United States, on both the macro and micro levels 
(55), how might we understand the infusion of racial organizing principles into the 
technological organization of knowledge after World War II? 

Omi and Winant and other scholars have tracked the emergence of a “race- 
blind” rhetoric at midcentury, a discourse that moves from overt to more covert 
modes of racism and racial representation (e.g., from the era of Jim Crow to lib- 
eral colorblindness). Drawing from those 3-D postcards that bring two or more 
images together even while suppressing their connections, I have earlier termed the 
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racial paradigms of the postwar era “lenticular logics.” The ridged coating on 3-D 
postcards is actually a lenticular lens, a structural device that makes simultaneously 
viewing the various images contained on one card nearly impossible. The viewer can 
rotate the card to see any single image, but the lens itself makes seeing the images 
together very difficult, even as it conjoins them at a structural level (i-e., within the 
same card). In the post—civil rights United States, the lenticular is a way of organiz- 
ing the world. It structures representations but also epistemologies. It also serves 
to secure our understandings of race in very narrow registers, fixating on sameness 
or difference while forestalling connection and interrelation. As I have argued else- 
where, we might think of the lenticular as a covert mode of the pretense of separate 
but equal, remixed for midcentury America (McPherson, 250). 

A lenticular logic is a covert racial logic, a logic for the post—civil rights era. We 
might contrast the lenticular postcard to that wildly popular artifact of the indus- 
trial era, the stereoscope card. The stereoscope melds two different images into an 
imagined whole, privileging the whole; the lenticular image partitions and divides, 
privileging fragmentation. A lenticular logic is a logic of the fragment or the chunk, 
a way of seeing the world as discrete modules or nodes, a mode that suppresses 
relation and context. As such, the lenticular also manages and controls complexity. 

And what in the world does this have to do with those engineers laboring away 
at Bell Labs, the heroes of the first fragment of history this essay began with? What’s 
race got to do with that? The popularity of lenticular lenses, particularly in the form 
of postcards, coincides historically not just with the rise of an articulated movement 
for civil rights but also with the growth of electronic culture and the birth of digital 
computing (with both—digital computing and the civil rights movement—born in 
quite real ways of World War II). We might understand UNIX as the way in which 
the emerging logics of the lenticular and of the covert racism of color blindness get 
ported into our computational systems, both in terms of the specific functions of 
UNIX as an operating system and in the broader philosophy it embraces. 


SITUATING UNIX 


In moving toward UNIX from MULTICS, programmers conceptualized UNIX as a 
kind of tool kit of “synergistic parts” that allowed “flexibility in depth” (Raymond, 
9). Programmers could “choose among multiple shells. ... [and] programs normally 
provide[d] many behavior options” (6). One of the design philosophies driving 
UNIX is the notion that a program should do one thing and do it well (not unlike 
our deep disciplinary drive in many parts of the university); this privileging of the 
discrete, the local, and the specific emerges again and again in discussions of UNIX’s 
origins and design philosophies. 

Books for programmers that explain the UNIX philosophy revolve around a 
common set of rules. While slight variations on this rule set exist across program- 
ming books and online sites, Eric Raymond sets out the first nine rules as follows: 
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. Rule of Modularity: Write simple parts connected by clean interfaces. 
. Rule of Clarity: Clarity is better than cleverness. 
. Rule of Composition: Design programs to be connected to other programs. 


ew nN 


. Rule of Separation: Separate policy from mechanism; separate interfaces 
from engines. 

5. Rule of Simplicity: Design for simplicity; add complexity only where you 
must. 

6. Rule of Parsimony: Write a big program only when it is clear by demonstra- 
tion that nothing else will do. 

7. Rule of Transparency: Design for visibility to make inspection and debug- 
ging easier. 

8. Rule of Robustness: Robustness is the child of transparency and simplicity. 

9. Rule of Representation: Fold knowledge into data so program logic can be 

stupid and robust. (13) 


Other rules include the Rules of Least Surprise, Silence, Repair, Economy, Genera- 
tion, Optimization, Diversity, and Extensibility.’ 

These rules implicitly translate into computational terms the chunked logics of 
the lenticular. For instance, Brian Kernighan wrote in a 1976 handbook on software 
programming that “controlling complexity is the essence of computer program- 
ming” (quoted in Raymond, 14). Complexity in UNIX is controlled in part by the 
Rule of Modularity, which insists that code be constructed of discrete and inter- 
changeable parts that can be plugged together via clean interfaces. In Design Rules, 
Vol. 1: The Power of Modularity, Carliss Baldwin and Kim Clark argue that comput- 
ers from 1940 to 1960 had “complex, interdependent designs,” and they label this era 
the “premodular” phase of computing (149). While individuals within the industry, 
including John von Neumann, were beginning to imagine benefits to modularity in 
computing, Baldwin and Clark note that von Neumann’s ground-breaking designs 
for computers in that period “fell short of true modularity” because “in no sense 
was the detailed design of one component going to be hidden from the others: all 
pieces of the system would be produced ‘in full view of the others” (157). Thus one 
might say that these early visions of digital computers were neither modular nor 
lenticular. Baldwin and Clark track the increasing modularity of hardware design 
from the early 1950s forward and also observe that UNIX was the first operating 
system to embrace modularity and adhere “to the principles of information hid- 
ing” in its design (324). 

There are clearly practical advantages of such structures for coding, but they 
also underscore a worldview in which a troublesome part might be discarded with- 
out disrupting the whole. Tools are meant to be “encapsulated” to avoid “a tendency 
to involve programs with each others’ internals” (Raymond, 15). Modules “don’t 
promiscuously share global data,” and problems can stay “local” (84-85). In writ- 
ing about the Rule of Composition, Eric Raymond advises programmers to “make 
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[programs] independent.” He writes, “It should be easy to replace one end with a 
completely different implementation without disturbing the other” (15). Detach- 
ment is valued because it allows a cleaving from “the particular ... conditions under 
which a design problem was posed. Abstract. Simplify. Generalize” (95). While “gen- 
eralization” in UNIX has specific meanings, we might also see at work here the basic 
contours of a lenticular approach to the world, an approach that separates object 
from context, cause from effect. 

In a 1976 article, “Software Tools,” Bell Lab programmers Kernighan and P. J. 
Plauger urged programmers “to view specific jobs as special cases of general, fre- 
quently performed operations, so they can make and use general-purpose tools to 
solve them. We also hope to show how to design programs to look like tools and to 
interconnect conveniently” (1). While the language here is one of generality (as in 
“general purpose” tools), in fact, the tool library that is being envisioned is a series 
of very discrete and specific tools or programs that can operate independently of 
one another. They continue, “Ideally, a program should not know where its input 
comes from nor where its output goes. The UNIX time-sharing system provides a 
particularly elegant way to handle input and output redirection” (2). Programs can 
profitably be described as filters, even though they do quite complicated transfor- 
mations on their input. One should be able to say 


program-1...| sort! program-2... 


and have the output of program-1 sorted before being passed to program-2. This 
has the major advantage that neither program-1 nor program-2 need know how to 
sort, but can concentrate on its main task (4). 

In effect, the tools chunk computational programs into isolated bits where the 
programs’ operations are meant to be “invisible to the user” and to the other pro- 
grams in a sequence: “the point is that this operation is invisible to the user (or 
should be)... . Instead he sees simply a program with one input and one output. 
Unsorted data go in one end; somewhat later, sorted data come out the other. It must 
be convenient to use a tool, not just possible” (5). Kernighan and Plauger saw the 
“filter concept” as a useful way to get programmers to think in discrete bits and to 
simplify their code, reducing the potential complexity of programs. They note that 
“when a job is viewed as a series of filters, the implementation simplifies, for it is 
broken down into a sequence of relatively independent pieces, each small and easily 
tested. This is a form of high-level modularization” (5). In their own way, these fil- 
ters function as a kind of lenticular frame or lens, allowing only certain portions of 
complex data sets to be visible at a particular time to both the user and the machine. 

The technical feature that allowed UNIX to achieve much of its modularity was 
the development by Ken Thompson (based on a suggestion by Doug Mcllroy) of the 
pipe—that is, a vertical bar that replaced the symbol for greater than (>) in the oper- 
ating system’s code. As described by Doug Ritchie and Ken Thompson in a paper for 
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the Association of Computing Machinery in 1974 (reprinted by Bell Labs in 1978), 
“A read using a pipe file descriptor waits until another process writes using the file 
descriptor for the same pipe. At this point, data are passed between the images of the 
two processes. Neither process need know that a pipe, rather than an ordinary file, is 
involved” (480). In this way, the ability to construct a pipeline from a series of small 
programs evolved, while the “hiding of internals” was also supported. The contents 
of a module were not central to the functioning of the pipeline; rather, the input 
or output (a text stream) was key. Brian Kernighan noted “that while input/output 
direction predates pipes, the development of pipes led to the concept of tools— 
software programs that would be in a ‘tool box, available when you need them” 
and interchangeable.* Pipes reduced complexity and were also linear. In “Software 
Tools,” Kernighan and Plauger extend their discussion of pipes, noting that “a pipe 
provides a hidden buffering between the output of one program and the input of 
another program so information may pass between them without ever entering the 
file system” (2). They also signal the importance of pipes for issues of data security: 


And consider the sequence 

decrypt key <file | prog | encrypt key > newfile 

Here a decryption program decodes an encrypted file, passing the decoded 
characters to a program having no special security features. The ouput of the 
program is re-encrypted at the other end. If a true pipe mechanism is used, no 
clear-text version of the data will ever appear in a file. To simulate this sequence 


with temporary files risks breaching security. (3) 


While the affordances of filters, pipes, and hidden data are often talked about as a 
matter of simple standardization and efficiency (as when Kernighan and Plauger 
argue that “our emphasis here has been on getting jobs done with an efficient use 
of people” [6]), they also clearly work in the service of new regimes of security, not 
an insignificant detail in the context of the cold war era. Programming manuals and 
UNIX guides again and again stress clarity and simplicity (don’t write fancy code; 
say what you mean as clearly and directly as you can), but the structures of oper- 
ating systems like UNIX function by hiding internal operations, skewing “clarity” 
in very particular directions. These manuals privilege a programmer’s equivalent 
of common sense in the Gramscian sense. For Antonio Gramsci, common sense 
is a historically situated process, the way in which a particular group responds to 
“certain problems posed by reality which are quite specific” at a particular time 
(324). As programmers constituted themselves as a particular class of workers in the 
1970s, they were necessarily lodged in their moment, deploying common sense and 
notions about simplicity to justify their innovations in code. Importantly, and as we 
will see, this moment is overdetermined by the ways in which the United States is 
widely coming to process race and other forms of difference in more covert registers, 
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as noted earlier, even if the programmers themselves do not explicitly understand 
their work to be tied to such racial paradigms.’ 

Another rule of UNIX is the Rule of Diversity, which insists on a mistrust of 
the “one true way.” Thus UNIX, in the words of one account, “embraces multiple 
languages, open extensible systems and customization hooks everywhere,” reading 
much like a description of the tenets of neoliberal multiculturalism (Raymond, 24). 
Certain words emerge again and again throughout the ample literature on UNIX: 
modularity, compactness, simplicity, orthogonality. UNIX is meant to allow mul- 
titasking, portability, time sharing, and compartmentalizing. It is not much of a 
stretch to layer these traits over the core tenets of post-Fordism, a mode of produc- 
tion that begins to remake industrial-era notions of standardization in the 1960s: 
time-space compression, transformability, customization, a public/private blur, 
and so on. UNIX’s intense modularity and information-hiding capacity were rein- 
forced by its design—that is, in the ways in which it segregated the kernel from the 
shell. The kernel loads into the computer’s memory at start-up and is “the heart” of 
UNIX (managing “hardware memory, job execution, and time sharing”), although 
it remains hidden from the user (Baldwin and Clark, 332). The shells (or programs 
that interpret commands) are intermediaries between the user and the computer’s 
inner workings. They hide the details of the operating system from the user behind 
“the shell,” extending modularity from a rule for programming in UNIX to the very 
design of UNIX itself."° 


Modularity in the Social Field 


This push toward modularity and the covert in digital computation also reflects 
other changes in the organization of social life in the United States by the 1960s. 
For instance, if the first half of the twentieth century laid bare its racial logics, from 
“Whites Only” signage to the brutalities of lynching, the second half increasingly 
hides its racial “kernel,” burying it below a shell of neoliberal pluralism. These covert 
racial logics take hold at the tail end of the civil rights movement at least partially 
to cut off and contain the more radical logics implicit in the urban uprisings that 
shook Detroit, Watts, Chicago, and Newark. In fact, the urban center of Detroit 
was more segregated by the 1980s than in previous decades, reflecting a different 
inflection of the programmer’s vision of the “easy removal” or containment of a 
troubling part. Whole areas of the city might be rendered orthogonal and dispos- 
able (also think post-Katrina New Orleans), and the urban black poor were increas- 
ingly isolated in “deteriorating city centers” (Sugrue, 198). Historian Thomas Sug- 
rue traces the increasing unemployment rates for black men in Detroit, rates that 
rose dramatically from the 1950s to the 1980s, and maps a “deproletarianization” 
that “shaped a pattern of poverty in the postwar city that was surprisingly new” 
(262). Across several registers, the emerging neoliberal state begins to adopt the Rule 
of Modularity. For instance, we might draw an example from across the Atlantic. In 
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her careful analysis of the effects of May 1968 and its afterlives, Kristin Ross argues 
that the French government contained the radical force of the uprisings by quickly 
moving to separate the students’ rebellion from the concerns of labor, deploying a 
strategy of separation and containment in which both sides (students and labor) 
would ultimately lose (69). 

Modularity in software design was meant to decrease “global complexity” and 
cleanly separate one “neighbor” from another (Raymond, 85). These strategies also 
played out in ongoing reorganizations of the political field throughout the 1960s 
and 1970s in both the Right and the Left. The widespread divestiture in the infra- 
structure of inner cities can be seen as one more insidious effect of the logic of 
modularity in the postwar era. But we might also understand the emergence of 
identity politics in the 1960s as a kind of social and political embrace of modular- 
ity and encapsulation, a mode of partitioning that turned away from the broader 
forms of alliance-based and globally inflected political practice that characterized 
both labor politics and antiracist organizing in the 1930s and 1940s.'! While identity 
politics produced concrete gains in the world, particularly in terms of civil rights, 
we are also now coming to understand the degree to which these movements cur- 
tailed and short-circuited more radical forms of political praxis, reducing struggle 
to fairly discrete parameters. 

Let me be clear. By drawing analogies between shifting racial and political for- 
mations and the emerging structures of digital computing in the late 1960s, I am 
not arguing that the programmers creating UNIX at Bell Labs and in Berkeley were 
consciously encoding new modes of racism and racial understanding into digital 
systems. (Indeed, many of these programmers were themselves left-leaning hippies, 
and the overlaps between the counterculture and early computing culture run deep, 
as Fred Turner has illustrated.) I also recognize that their innovations made possible 
the word processor I am using to write this article, a powerful tool that shapes cog- 
nition and scholarship in precise ways. Nor am I arguing for some exact correspon- 
dence between the ways in which encapsulation or modularity work in computation 
and how they function in the emerging regimes of neoliberalism, governmental- 
ity, and post-Fordism. Rather, I am highlighting the ways in which the organiza- 
tion of information and capital in the 1960s powerfully responds—across many 
registers—to the struggles for racial justice and democracy that so categorized the 
United States at the time. Many of these shifts were enacted in the name of liberal- 
ism, aimed at distancing the overt racism of the past even as they contained and cor- 
doned off progressive radicalism. The emergence of covert racism and its rhetoric of 
color blindness are not so much intentional as systemic. Computation is a primary 
delivery method of these new systems, and it seems at best naive to imagine that 
cultural and computational operating systems don’t mutually infect one another. 

Thus we see modularity take hold not only in computation but also in the 
increasingly niched and regimented production of knowledge in the university after 
World War II. For instance, Christopher Newfield comments on the rise of New 
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Criticism in literature departments in the cold war era, noting its relentless for- 
malism, a “logical corollary” to “depoliticization” (145) that “replaced agency with 
technique” (155). He attributes this particular tendency in literary criticism at least 
in part to the triumph of a managerial impulse, a turn that we might also align 
(even if Newfield doesn’t) with the workings of modular code (itself studied as an 
exemplary approach to dynamic modeling systems for business management in the 
work of Baldwin and Clark cited earlier.)’* He observes as well that this managerial 
obsession within literary criticism exhibits a surprising continuity across the 1960s 
and beyond. Gerald Graff has also examined the “patterned isolation” that emerges 
in the university after World War II, at the moment when New Criticism’s meth- 
ods take hold in a manner that deprivileges context and focuses on “explication for 
explication’s sake.” Graff then analyzes the routinization of literary criticism in the 
period, a mechanistic exercise with input and output streams of its own (227). He 
recognizes that university departments (his example is English) begin to operate 
by a field-based and modular strategy of “coverage,” in which subfields proliferate 
and exist in their own separate chunks of knowledge, rarely contaminated by one 
another’s “internals” (250). (He also comments that this modular strategy includes 
the token hiring of scholars of color who are then cordoned off within the depart- 
ment.) Graff locates the beginning of this patterned isolation in the run-up to the 
period that also brought us digital computing; he writes that it continues to play 
out today in disciplinary structures that have become increasingly narrow and spe- 
cialized. Patterned isolation begins with the bureaucratic standardization of the 
university from 1890 through 1930 (61-62), but this “cut out and separate” men- 
tality reaches a new crescendo after World War II as the organizational structure of 
the university pushes from simply bureaucratic and Taylorist to managerial, a shift 
noted as well by Christopher Newfield. Many now lament the overspecialization of 
the university; in effect, this tendency is a result of the additive logic of the lenticular 
or of the pipeline, where “content areas” or “fields” are tacked together without any 
sense of intersection, context, or relation. Today, we risk adding the digital humani- 
ties to our proliferating disciplinary menus without any meaningful and substantial 
engagement with fields such as gender studies or critical race theory. 

It is interesting to note that much of the early work performed in UNIX envi- 
ronments was focused on document processing and communication tools and that 
UNIX is a computational system that very much privileges text (it centers on the 
text-based command line instead of on the graphical user interface, and its inputs 
and outputs are simple text lines). Many of the methodologies of the humanities 
from the cold war through the 1980s also privilege text while devaluing context and 
operate in their own chunked systems, suggesting telling parallels between the oper- 
ating systems and privileged objects of the humanities and of the computers being 
developed on several university campuses in the same period. 

Lev Manovich has, of course, noted the modularity of the digital era and also 
backtracked to early twentieth-century examples of modularity from the factory 
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line to the creative productions of avant garde artists. In a posting to the Nettime 
listserv in 2005, he frames modularity as a uniquely twentieth-century phenom- 
enon, from Henry Ford’s assembly lines to the 1932 furniture designs of Belgian 
designer Louis Herman De Kornick. In his account, the twentieth century is char- 
acterized by an accelerating process of industrial modularization, but I think it is 
useful to examine the digital computer’s privileged role in the process, particularly 
given that competing modes of computation were still quite viable until the 1960s, 
modes that might have pushed more toward the continuous flows of analog com- 
puting rather than the discrete tics of the digital computer. Is the modularity of the 
1920s really the same as the modularity modeled in UNIX? Do these differences 
matter, and what might we miss if we assume a smooth and teleological triumph of 
modularity? How has computation pushed modularity in new directions, directions 
in dialogue with other cultural shifts and ruptures? Why does modularity emerge 
in our systems with such a vengeance across the 1960s? 

I have here suggested that our technological formations are deeply bound up 
with our racial formations and that each undergo profound changes at midcentury. 
Iam not so much arguing that one mode is causally related to the other but, rather, 
that they both represent a move toward modular knowledges, knowledges increas- 
ingly prevalent in the second half of the twentieth century. These knowledges sup- 
port and enable the shift from the overt standardized bureaucracies of the 1920s 
and 1930s to the more dynamically modular and covert managerial systems that 
are increasingly prevalent as the century wears on. These latter modes of knowledge 
production and organization are powerful racial and technological operating sys- 
tems that coincide with (and reinforce) (post)structuralist approaches to the world 
within the academy. Both the computer and the lenticular lens mediate images 
and objects, changing their relationship but frequently suppressing that process of 
relation, much like the divided departments of the contemporary university. The 
fragmentary knowledges encouraged by many forms and experiences of the digital 
neatly parallel the logics that underwrite the covert racism endemic to our times, 
operating in potential feedback loops, supporting each other. If scholars of race have 
highlighted how certain tendencies within poststructuralist theory simultaneously 
respond to and marginalize race, this maneuver is at least partially possible because 
of a parallel and increasing dispersion of electronic forms across culture, forms that 
simultaneously enact and shape these new modes of thinking. 

While the examples here have focused on UNIX, it is important to recognize 
that the core principles of modularity that it helped bring into practice continue 
to impact a wide range of digital computation, especially the C programming lan- 
guage, itself developed for UNIX by Ritchie, based on Thompson’s earlier B lan- 
guage. While UNIX and C devotees will bemoan the nonorthogonality and leaki- 
ness of Windows or rant about the complexity of C++, the basic argument offered 
earlier—that UNIX helped inaugurate modular and lenticular systems broadly 
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across computation and culture—holds true for the black boxes of contemporary 
coding and numerous other instances of our digital praxis. 

Today, we might see contemporary turns in computing—neural nets, clouds, 
semantics, and so on—as parallel to recent turns in humanities scholarship to privi- 
lege networks over nodes (particularly in new media studies and in digital culture 
theory) and to focus on globalization and its flows (in American studies and other 
disciplines). While this may simply mean we have learned our midcentury lessons 
and are smarter now, we might also continue to examine with rigor and detail the 
degree to which dominant forms of computation—what David Golumbia has aptly 
called “the cultural logic of computation” in his recent update of Frankfurt School 
pessimism for the twenty-first century—continue to respond to shifting racial and 
cultural formations. Might these emerging modes of computation be read as symp- 
toms and drivers of our postracial moment, refracting in some way national anxi- 
eties (or hopes) about a decreasingly white America? We should also remain alert 
to how contemporary technoracial formations infect privileged ways of knowing 
in the academy. While both the tales of C. P. Snow circa 1959 and the Sokal science 
wars of the 1990s sustain the myth that science and the humanities operate in dis- 
tinct realms of knowing, powerful operating systems have surged beneath the sur- 
face of what and how we know in the academy for well over half a decade. It would 
be foolish of us to believe that these operating systems—in this paper best catego- 
rized by UNIX and its many close siblings—do not at least partially overdetermine 
the very critiques we imagine that we are performing today. 


Moving Beyond Our Boxes 


So if we are always already complicit with the machine, what are we to do? 

First, we must better understand the machines and networks that continue 
to powerfully shape our lives in ways that we are often ill equipped to deal with as 
media and humanities scholars. This necessarily involves more than simply study- 
ing our screens and the images that dance across them, moving beyond the study of 
representations and the rhetorics of visuality. We might read representations seek- 
ing symptoms of information capital’s fault lines and successes, but we cannot read 
the logics of these systems and networks solely at the level of our screens. Capital is 
now fully organized under the sign of modularity. It operates via the algorithm and 
the database, via simulation and processing. Our screens are cover stories, disguis- 
ing deeply divided forms of both machine and human labor. We focus exclusively 
on them increasingly to our peril. 

Scholars in the digital humanities and in the emerging field of code studies are 
taking up the challenge of understanding how computational systems (especially 
but not only software) developed and operate. However, we must demand that 
these fields not replay the formalist and structuralist tendencies of new media the- 
ory circa 1998. This formalist turn displayed a stubborn technological determinism 
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and often privileged the machine over the social. To end run such determinism, the 
digital humanities and code studies must also take up the questions of culture and 
meaning that animate so many scholars of race in fields like the new American stud- 
ies. Likewise, scholars of race must analyze, use, and produce digital forms and not 
smugly assume that to engage the digital directly is to be complicit with the forces 
of capitalism. The lack of intellectual generosity across our fields and departments 
only reinforces the divide-and-conquer mentality that the most dangerous aspects 
of modularity underwrite. We must develop common languages that link the study 
of code and culture. We must historicize and politicize code studies. And, because 
digital media were born as much of the civil rights era as of the cold war era (and 
of course these eras are one and the same), our investigations must incorporate 
race from the outset, understanding and theorizing its function as a ghost in the 
digital machine. This does not mean that we should simply add race to our analysis 
in a modular way, neatly tacking it on or building digital archives of racial mate- 
rial, but that we must understand and theorize the deep imbrications of race and 
digital technology even when our objects of analysis (say UNIX or search engines) 
seem not to be about race at all. This will not be easy. In the writing of this essay, 
the logic of modularity continually threatened to take hold, leading me into detailed 
explorations of pipe structures in UNIX or departmental structures in the univer- 
sity, taking me far from the contours of race at midcentury. It is hard work to hold 
race and computation together in a systemic manner, but it is work that we must 
continue to undertake. 

We also need to take seriously the possibility that questions of representation 
and of narrative and textual analysis may, in effect, divert us from studying the 
reorganization of capital—a reorganization dependent on the triumph of the very 
particular patterns of informationalization evident in code. If the study of repre- 
sentation may in fact be part and parcel of the very logic of modularity that such 
code inaugurates, a kind of distraction, it is equally plausible to argue that our very 
intense focus on visuality in the past twenty years of scholarship is just a different 
manifestation of the same distraction. There is tendency in film and media studies 
to treat the computer and its screens as (in Jonathan Beller’s terms) a “legacy” tech- 
nology to cinema. In its drive to stage continuities, such an argument tends to mini- 
mize or completely miss the fundamental material differences between cinematic 
visuality and the production of the visual by digital technologies. For most of the 
twentieth century, cinema was a profoundly visual (if also aural) form, with images 
etched into celluloid; the digital does not depend on vision in any analogous way. 

To push my polemic to its furthest dimensions, I would argue that to study 
image, narrative, and visuality will never be enough if we do not engage as well the 
nonvisual dimensions of code and their organization of the world. Yet to trouble 
my own polemic, we might also understand the workings of code to have already 
internalized the visual to the extent that, in the heart of the labs from which UNIX 
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emerged, the cultural processing of the visual via the register of race was already at 
work in the machine. 

In extending our critical methodologies, we must have at least a passing famil- 
iarity with code languages, operating systems, algorithmic thinking, and systems 
design. We need database literacies, algorithmic literacies, computational literacies, 
interface literacies. We need new hybrid practitioners: artist-theorists, program- 
ming humanists, activist-scholars; theoretical archivists, critical race coders. We 
need new forms of graduate and undergraduate education that hone both critical 
and digital literacies. We have to shake ourselves out of our small, field-based boxes 
so that we might take seriously the possibility that our own knowledge practices are 
normalized, modular, and black boxed in much the same way as the code we study 
in our work. That is, our very scholarly practices tend to undervalue broad contexts, 
meaningful relation, and promiscuous border crossing. While many of us identify 
as interdisciplinary, very few of us extend that border crossing very far (theorists 
tune out the technical; the technologists are impatient of the abstract; scholars of 
race mock the computational, seeing it as corrupt). The intense narrowing of our 
academic specialties over the past fifty years can actually be seen as an effect of or 
as complicit with the logics of modularity and the relational database. Just as the 
relational database works by normalizing data—that is, by stripping it of meaning- 
ful, idiosyncratic context, creating a system of interchangeable equivalencies—our 
own scholarly practices tend to exist in relatively hermetically sealed boxes or nodes. 
Critical theory and poststructuralism have been powerful operating systems that 
have served us well; they were as hard to learn as the complex structures of C++, and 
we have dutifully learned them. They are also software systems in desperate need of 
updating and patching. They are lovely, and they are not enough. They cannot be 
all we do, but that is not to say that they are not of any value. 

In universities that simply shut down “old school” departments—like at my 
university, German and geography; in the UK, Middlesex’s philosophy program; 
in Arizona, perhaps all of ethnic studies; in Albany, anything they can—scholars 
must engage the vernacular digital forms that make us nervous, authoring in them 
in order to better understand them and to recreate in technological spaces the pos- 
sibility of doing the work that moves us. We need new practices and new modes 
of collaboration; we need to be literate in emerging scientific and technological 
methodologies but also in theories of race, globalization, and gender. We'll gain 
that literacy at least partially through an intellectual generosity or curiosity toward 
colleagues whose practices are not our own. We need to privilege systemic modes 
of thinking that can understand relation and honor complexity, even while valu- 
ing precision and specificity. We need nimbler ways of linking the network and the 
node and digital form and content, and we need to understand that categories like 
race profoundly shape both form and content. In short, we need a good deal more 
exchange between the ASA and the digital humanities so that we might develop 
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some shared languages and goals. We must take seriously the question, why are the 
digital humanities so white? but also ask why American studies is not more digital. 

We must remember that computers are themselves encoders of culture. If, in 
the 1960s and 1970s, UNIX hardwired an emerging system of covert racism into 
our mainframes and our minds, then computation responds to culture as much as 
it controls it. Code and race are deeply intertwined, even as the structures of code 
labor to disavow these very connections.'* Politically committed academics with 
humanities skill sets must engage technology and its production not simply as an 
object of our scorn, critique, or fascination but as a productive and generative space 
that is always emergent and never fully determined. 


NOTES 


1. For the past decade, I have had the privilege to work with a team of collaborators 

on a variety of digital projects, including the online journal Vectors and a new authoring 
platform Scalar. In Los Angeles, this team includes Steve Anderson, Craig Dietrich, and 
Erik Loyer (and, until recently, Raegan Kelly), among others, and it is impossible to over- 
state how thoroughly I have been reconfigured by the opportunity to interact with such 
smart and congenial people. Conversations over the years (including at the Baltimore sum- 
mit) with the broader DH community have deeply shaped our approach to developing 
computational systems for the humanities. 
This essay is a revised version of a piece originally written for Race after the Internet, edited 
by Peter Chow-White and Lisa Nakamura, forthcoming from Routledge. Feedback from 
Neil Fraistat, Matt Gold, David Golumbia, and Steve Ramsay helped sharpen the piece 
for this volume. 

2. This panel was organized by Glenn Hendler and Bruce Burgett, both of whom 
have worked quite tirelessly to engage the ASA community in conversations about the dig- 
ital humanities. In addition to the three of us, Randy Bass, Sharon Daniel, Deborah Kim- 
mey, and Curtis Marez were also on the panel. Tim Powell had been on the original pro- 
gram but was unable to attend. 

3. These tensions between traditional humanities scholars and computational 
humanists are, of course, not new. For examples of these dynamics within early waves of 
humanities computing, see Thomas, “Computing and the Historical Imagination,” and 
Craig, “Stylistic Analysis and Authorship Studies.” As these authors note from within the 
realms of authorship studies and historical studies, these tensions often played out over 
the differences between quantitative and qualitative analysis and via debates on the sta- 
tus and validity of various modes of interpretation. Two readers (Golumbia and Ram- 
say) of this piece during the volume’s semiopen peer review process expressed discomfort 
with the use of the term “traditional” to describe humanities scholars who don’t consider 
themselves DHers. I share that discomfort, particularly since the word “traditional” seems 


to imply conservative, not a term many would associate with the ASA today, at least in a 
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political sense. Instead, I mean the term simply to signal scholars in the humanities whose 
methodologies are not primarily dependent on digital analysis, platforms, or tools. 

4. UNIX develops with some rapidity at least in part because the parent company of 
Bell Labs, AT&T, was unable to enter the computer business due to a 1958 consent decree. 
Eric Raymond notes that “Bell Labs was required to license its nontelephone technology 
to anyone who asked” (33). Thus a kind of counterculture chic developed around UNIX. 
Raymond provides a narrative version of this history, including the eventual UNIX wars, 
in his The Art of UNIX Programming. His account, while thorough, tends to romanticize 
the collaborative culture around UNIX. For a more objective analysis of the imbrications 
of the counterculture and early computing cultures, see Fred Turner’s From Countercul- 
ture to Cyberculture. See also Tom Streeter for a consideration of liberal individualism and 
computing cultures. 

5. Critical code studies (and software studies more generally) take up the study of 
computational systems in a variety of ways. For an overview of software studies, see Fuller. 
For emerging work in critical code studies, see the proceedings of the 2010 conference on 
Critical Code Studies, archived at http://vectorsjournal.org/thoughtmesh/critcode. 

6. Some scholars have questioned the neutral status of digital structures such as 
code and databases. John Unsworth has situated UNIX as a Western cultural formation, 
arguing that “UNIX is deeply indebted to culturally determined notions such as private 
property, class membership, and hierarchies of power and effectivity. Most of these ideas 
are older than the modern Western culture that produced UNIX, but the constellation of 
cultural elements gathered together in UNIX’s basic operating principles seems particu- 
larly Western and capitalist—not surprisingly, given that its creators were human exten- 
sions of one of the largest accumulations of capital in the Western world” (142). See also 
David Golumbia’s observations on the limits of the database and of semantic computing 
for humanities analysis, as well as work on culturally contextual databases and ontologies 
undertaken by Kimberly Christen and Ramesh Srinivasan. Golumbia has further argued 
that object-oriented programming privileges categorization and hierarchies in a man- 
ner that has “much more to do with engineering presumptions and ideologies than with 
computational efficiency” (209). His work is a must read for anyone caught up in utopian 
readings of digital culture’s empowering and participatory aspects. 

7. In comments on a draft of this essay, Steve Ramsay suggested that Mike Gancarz’s 
The Unix Philosophy categorizes UNIX via a related but different rule set. His rule set (4-5) 
is as follows: 

1. Small is beautiful. 
. Make each program do one thing well. 
. Build a prototype as soon as possible. 


. Store data in flat text files. 


2 

3 

4. Choose portability over efficiency. 

5 

6. Use software leverage to your advantage. 
7 


. Use shell scripts to increase leverage and portability. 
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8. Avoid captive user interfaces. 

9. Make every program a filter. 
Both Raymond and Gancarz privilege many of the same elements, including modularity, 
portability, and a certain notion of simplicity. See, for example, Gancarz’s discussion of 
code modules and pipes (116). 

8. This quote from Kernighan is from “The Creation of the UNIX Operating System” 
on the Bell Labs website. See http://www.bell-labs.com/history/unix/philosophy.html. 

9. For Gramsci, “common sense” is a multilayered phenomenon that can serve both 
dominant groups and oppressed ones. For oppressed groups, common sense may allow a 
method of speaking back to power and of rejiggering what counts as sensible. Kara Keeling 
profitably explores this possibility in her work on the black femme. Computer program- 
mers in the 1970s are interestingly situated. They are on the one hand a subculture (often 
overlapping with the counterculture), but they are also part of an increasingly manage- 
rial class that will help society transition to regimes of neoliberalism and governmental- 
ity. Their dreams of libraries of code may be democratic in impulse, but they also increas- 
ingly support postindustrial forms of labor. 

10. Other aspects of UNIX also encode “chunking,” including the concept of the file. 
For a discussion of files in UNIX, see You Are Not a Gadget by Jaron Lanier. This account 
of UNIX, among other things, also argues that code and culture exist in complex feedback 
loops. 

11. See, for instance, Patricia Sullivan’s Days of Hope for an account of the coali- 
tion politics of the South in the 1930s and 1940s that briefly brought together antiracist 
activists, labor organizers, and members of the Communist Party. Such a broad alliance 
became increasingly difficult to sustain after the Red Scare. I would argue that a broad cul- 
tural turn to modularity and encapsulation was both a response to these earlier political 
alliances and a way to short circuit their viability in the 1960s. My Reconstructing Dixie 
examines the ways in which a lenticular logic infects both identity politics and the poli- 
tics of difference, making productive alliance and relationality hard to achieve in either 
paradigm. 

12. To be fair, Newfield also explores a more radical impulse in literary study in the 
period, evident in the likes of (surprisingly) both Harold Bloom and Raymond Williams. 
This impulse valued literature precisely in its ability to offer an “unmanaged exploration 
of experience” (152). 

13. There is no smoking gun that can unequivocally prove a one-to-one equation 
between shifting parameters of racial representation and racism and the emergence of 
UNIX as a very particular development in the history of computing, one that was nei- 
ther necessary nor inevitable. Such proof is not my goal here. Rather, this essay asks why 
the midcentury turn to modularity was so deeply compelling and so widely dispersed, 
from urban planning to operating systems; I argue that in the United States this reorga- 
nization cannot be understood without taking into account the ways in which the nation 


responded to the civil rights movement. Of course, race is not the only axis of difference 
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driving cultural change at this moment; how we understand the politics of gender and 
sexuality are also changing and are important to consider in relation to this essay’s broad 
argument. In fact, we might understand the emergence of identity politics throughout 
the 1960s and 1970s as part of this very logic of modularity. But I would maintain that 
two broad things are true. First, society is reorganizing due to pressures within the polit- 
ical field (ie., due to social movements), and that race is a particularly important vector 
in this reorganization. Second, all technological change is deeply situated within cultural 
forces, and, thus, the development of UNIX needs to be read in relation to these changes 
even if the relationship is not one of strict linear causality. It has been interesting to note 
that, when presenting this work in various venues, scholars of race typically get the argu- 
ment, while others are sometimes more resistant. I would suggest that perhaps this very 
resistance might itself be an after effect of the triumph of modularity in the contempo- 


rary academy. 
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